home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000224_news@columbia.edu_Mon Nov 21 04:54:30 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA02974
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 21 Nov 1994 18:44:36 -0500
  3. Received: by apakabar.cc.columbia.edu id AA28253
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 21 Nov 1994 18:44:34 -0500
  5. Path: news.columbia.edu!news.media.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!agate!overload.lbl.gov!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc,alt.winsock
  8. Subject: Re: winsock/pkt dvr hack possible?
  9. Message-Id: <1994Nov21.105430.33454@cc.usu.edu>
  10. Date: 21 Nov 94 10:54:30 MDT
  11. References: <3a67j8$j39@Mercury.mcs.com> <3anvci$dut@relay.tor.hookup.net>  <soren.223.000F87E0@aztec.co.za>
  12. Organization: Utah State University
  13. Lines: 29
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:1168 alt.winsock:22603
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <soren.223.000F87E0@aztec.co.za>, soren@aztec.co.za (Soren Aalto) writes:
  18. > In article <3aoc2h$bit@apakabar.cc.columbia.edu> jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
  19. > 
  20. >>>>        Jeff is correct. The top of a sockets API is a TCP stream channel of
  21. >>>>bytes, not packets. "It could be done..." means creating a second TCP/IP
  22. >>>>stack feeding from the streams channel and packaging it into TCP/IP over
  23. >>>>Ethernet frames to be passed to the application. Not very desirable, nor 
  24. >>>>realistic.
  25. >>>>        Joe D.  
  26.     <huge amount of repeated material omitted>
  27. > And _that_ is the real problem.  I have wondered at times if the
  28. > TCP/IP stack functionality and the Comms/SLIP/PPP functionality
  29. > shouldn't be separated into two programs--you could have a
  30. > packet driver that "reflects" stuff & attach the comms driver
  31. > for SLIP/PPP/whatever to one side and Winsock to the other.
  32. -----------
  33.     Nice idea but not practical here. There are a great many
  34. coupling threads (variables, calls) between the high level and comms
  35. level material in Kermit so that control may be exercised and speed
  36. retained. And there is much more to comms than serial or the internal
  37. TCP/IP stack; SET PORT exhibits the list (and some choices transparently
  38. encompass two or three variations from the same vendor).
  39.     Winsock is for pure Windows programs, not for DOS programs.
  40.     MS-DOS Kermit removes itself from comms channels when done with
  41. them. Few commercial TCP/IP stacks do so (none that I know of). Were
  42. winsock guys to get off the pot when done the problem would be smaller.
  43. So please consider hounding your winsock vendor to go un-TSR upon last
  44. close and to not be present until an application makes a demand.
  45.     Joe D.